1.3. System Outputs

1.4. Variables

1.4.1. Variable Definition

Programmer can make variables and functions. This is a fundamental principle in programming.
In fact, only about variables, we’ve already demonstrated in chapter 1, and type definition.
However, also there are rules, I’ll show you below:

• we cannot overwrite value of variable
• we cannot define different variables but same name
• we can define type of variable
• we don’t have to write type with variables every time, because of Hindley/Milner Type System

1.4.2. Type Definition

For example…

True or False

C: β ← ⊥;
⎕ ← IF:κ[?] ← ⟨C, "TRUE", "FALSE"⟩;

FALSE

Numeric Matrix

M: φ[3 2] ← 3 4 ρ 3.24 9.00 5.68 ¯0.26 ¯5.84 0.88;
⎕ ← M;

3.24    9.00
5.68    ¯0.26
¯5.84   0.88

types of scalar are below:

variable size mappings are below:

1.5. Functions

1.5.1. Glyph Function and System Function

1.5.2. Monad Function and Dyad Function

In general, there are two types of functions in AROAPL.
These are “monad” and “dyad”.
Monad is the function with single argument, and dyad is the function with double arguments.
Strictly, there is also function with no arguments, called “nilad”. But it is comparatively rare and limited usages. I’ll explain this topic in next sub-section.

For example, plus method can be explained as a typical dyad function:

⎕ ← 2 + 3; 

5

Also, negate method can be explained as a typical monad function:

⎕ ← - ¯2;

2

By the way, minus as a negative value, and minus as a negation or a subtraction are distinguished as “higher minus” glyph and “hyphen minus” glyph in AROAPL.
If you use custom keyboard for AROAPL, you can code easily, so you don’t worry.

For more examples, I’ll introduce in next chapter.

As some of clevers may have already realized, in AROAPL, “function” means operator that is known commonly.
More details, rules of function are below:

• we call a function with single argument “monad” as [monad] A
• we call a function with double arguments “dyad” as A [dyad] B
• we call a function with no arguments “nilad” as [nilad]
• we call the count of arguments of function “arity”
• function returns with a value (including array and tuple structure)
• programmer can make custom function called user-defined function
• User-defined functions include anonymous functions
• User-defined functions does not include nilad functions
• programmer cannot declare user-defined named functions in any other user-defined functions
• functions are not first-class object

I’ll explain about user-defined functions in chapter 8.

Also, there is an attention to treat function. Please don’t refer to functions as operators, because there is also “operator” that is different to functions in AROAPL. In a nutshell, it doesn’t mean “operands in calculus” but “function manipulator”, but I’ll explain more details in chapter 4.

1.5.3. Nilad Function

As I mentioned in the previous sub-secion, there is another case as the special function, called “nilad”.
Nilad is the function with no arguments, and not always return the same value.
In a nutshell, it would be more accurate to call special values, rather than functions. Let me explain more details.

In middle or high school math classes, we encountered functions like this:

\[ f(x) = 3 \] Strictly speaking, this example includes the variable \(x\).
But regardless of the value of \(x\), it always returns \(3\).
This means that, from a more programming-oriented perspective, the following should also hold true:

\[ f() = 3 \]

What I want you to realize here is, this is no longer a function.
It is just a value.
Therefore, the interpretation is that a value without arguments is always constant, and functions without arguments should not be needed.

You also need to understand that for functions that take arguments, if the argument values are the same, the result will always be the same.

\[ f(x) = ax + b \]

So, why is nilad necessary?

The answer is simple, even for functions with no arguments, there are cases where the value is not always constant.

The simplest example woud be ⎕RAND (randomizer). This function returns different value even if we assign the same value.

As a principle of AROAPL, once a constant or variable is defined, it cannot be changed in any way. Nevertheless, if calling the same symbol returned a different value each time, that principle would no longer hold on.

In order to resolve this problem, AROAPL supports nilad function as a special exception.

1.5.4. Type Definition

1.6. Constants

Except nilad function, “constant” is fixed value as function with no arguments.
Glyph constants are below:

I’ll explain about nilad function in chapter 6.

1.7. Formula and Statement

This is the last topic of this chapter. And, perhaps, this is the most important because the feature is different from APL.
Except system outputs, there are no statements and they are altered as below:

• if statement → if function as IF:? ⟨β, ?, ?⟩ ( → chapter 5 )
• switch statement → switch function as SW:? ⟨⟨β, ?⟩[?], ?⟩ ( → chapter 5 )
• for-loop statement → array manipulations ( → chapter 3 )
• while-loop statement → recursion function as ∇ ( → chapter 8 )

And I’ll explain about system outputs in chapter 7. Also you can make custom system outputs.
Basicly, as we code with AROAPL, we need to be based on pure functional programming. But at the same time, we have to understand AROAPL is not pure functional programming language, too. In order to explain that, I appended chapter 12 dedicatedly. I named it “fake functional programming”.
At least for now, it is enough to know about the abstract of the alternative methods.

Also, this is advanced topic though, sometimes, textbooks in APL, it is mentioned that it is not recommended to use “If:”, “While:”, and so on, I don’t agree with. Regardless of actual performance of APL, programmer should be able to use them without any guilts.
Especially, “while” loop method is essential in the principle of programming. Array computation cannot be the alternative method completely of loop, for example, GPU calculation is bad at the requirements including auto-regressive processes.
This is also the reason why AROAPL has chosen AOT compiler rather than interpreter, and static type definition rather than dynamic type definition, I wanted to maximize speed at also unparallelizable loops.
On the other hand, when I think of the possibility of understanding programs, AROAPL was needed more additional approaches. At first, I used the Haskell as a reference, but after I had struggled as a while, finally, AROAPL has been like an original approach.
More details, I’ll explain it in chapter 12.

1.8. Pure Functional Principles in AROAPL

This is the last topic of this chapter. And, perhaps, this is the most important because the feature is different from APL.

1.8.1. Referential transparency

1.8.2. Side Effects

1.8.3. Mutablility and State Variables